Skip to content

fix(auth): support loopback MCP client registration - #2021

Open
edmonday wants to merge 8 commits into
mainfrom
codex/changelog-dynamic-client-registration
Open

fix(auth): support loopback MCP client registration#2021
edmonday wants to merge 8 commits into
mainfrom
codex/changelog-dynamic-client-registration

Conversation

@edmonday

@edmonday edmonday commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

Summary

Codex and Claude can now dynamically register separate native public OAuth clients for Changelog through exact HTTP loopback callbacks. Forge supplies omitted native/public metadata only when every redirect uses localhost, 127.0.0.1, or [::1]; explicit client types, confidential clients, and non-loopback or mixed registrations retain Better Auth's normal validation.

This is the Forge issuance half of the Changelog MCP integration. Changelog PR #79 owns the protected /mcp resource and list_entries tool. Production issuance remains disabled, and preview remains deferred until Changelog has a stable preview domain.

Design and safety

  • Qualifying clients are registered as native public clients without generated client secrets; PKCE remains required by the OAuth provider.
  • Unauthenticated JSON registration bodies are capped at 64 KiB before parsing, including mixed-case JSON media types.
  • Successful client registration grants no Changelog access. Existing Forge grant policy still narrows issued scopes to the user's approved application and environment grant.

Work Loop

  • ce:plan done — docs/roadmap/platform/feat-399-changelog-first-party-auth.md
  • ce:work done
  • ce:review done
  • ce:compound done

Notes

Local acceptance registered different Codex and Claude client identities and token families, narrowed both to the approved changelog:read grant, exercised authorization-code exchange and refresh/reconnect, read a real Changelog entry, and denied an ungranted capability. The earlier run covered browser consent end to end. The final post-fix receipt submitted the same authenticated consent payload directly because its temporary metadata proxy did not forward the Next.js development WebSocket.

The receipt is recorded in feat-399, which this PR marks complete. Production remained disabled throughout.

Validation:

  • 468 Forge Auth unit tests passed; 18 opt-in PostgreSQL integration tests were skipped locally and retain their existing CI coverage.
  • Focused route tests, Auth typecheck, and Auth lint passed.
  • The companion acceptance run also passed 104 Changelog tests and Changelog typecheck.

New concepts

OAuth loopback callback

A local CLI can open a temporary HTTP listener on the same computer and receive the browser's authorization response there. Exact loopback hosts never send the callback across the public network, so native clients may use HTTP for this narrow case; ordinary web callbacks still require HTTPS.

This PR recognizes the loopback pattern only when the client omitted its application type and every redirect is local. It does not relax Better Auth's validation for explicit web clients or public-network redirects.

Related: JesusFilm/jfp-changelog#71

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant